One of the important services provided by modern storage controller products is a copy services solution. Copy services include, but are not limited to, remote copy, point in time copy, and continuous data protection (CDP). These copy services are today typically implemented inside storage controllers as an integral part of the storage controller microcode. Recently, though, a new approach has emerged in the industry whereby copy services are implemented in an appliance which will here be called a “Replication Engine”, rather than inside a storage controller.
All the above copy services, or replication, functions rely on “writes” of the protected data being “split”. What this means is that the copy services appliance receives a notification that a write is ongoing synchronously with the write being performed to the storage controller.
In systems according to the prior art there are, broadly speaking, two distinct implementations of this splitter technology. These arrangements are shown in FIG. 1. Firstly there is the technique of using a splitter implemented in the fabric. This is shown on the left-hand side of FIG. 1, where host 100 is connected to SAN fabric 104, and SAN-based splitter 116 performs primary I/O to physical storage 106. SAN-based splitter 116 also directs I/O to replication engine 110, in which the copy services component 112 resides and performs copy services. The second technique is to implement a splitter in the host software stack, such as the device driver. The host operating system's logical volume manager (LVM) can also be used for this function. This arrangement is shown on the right-hand side of FIG. 1, where splitter 114 is connected to host 102 above the fabric level 104. In each of these implementations, the write data is sent from the splitter to the replication engine.
The disadvantages of all these schemes are:
1. Multiple different implementations are required to cover all host types and switch types.
2. Splitting in the host consumes host CPU MIPS and doubles write bandwidth requirement on the host to switch links.
3. Hosts and switches typically do not have access to non volatile memory. This means that it is hard for the hosts to reliably keep track of the state of in-flight writes, forcing design compromises which either impact performance, robustness or the speed at which the solution can recover from loss of power.
U.S. patent application Ser. No. 11/840,179 discloses a technique that permits implementation of a generic splitting protocol inside the Storage controller rather than in the host or in the storage area network (SAN). This protocol provides the infrastructure to build a common Copy Function across several different Storage Controllers. The interface is intended to be a simple interface that makes it possible to connect storage arrays (SA) to replication engines (RE) and to each other and allow new replication functions to be more rapidly deployed. This implementation relies on the use of a protocol in which each write command received by the splitter is duplicated and sent in parallel to both the primary storage and also to the replication engine. The replication engine has some storage, usually (but not required to be) provided by the same storage array that contains the splitter. The RE uses this as a “repository” to implement its copy services. This repository will typically contain the data that has been written to the primary disks, together possibly with older copies of the data which was on the primary disks at some time in the past, together with metadata. In this protocol, the commands used transfer both control information and the data that was received from the host. The expected implementation of a replication engine is that it will not include disk storage but will instead use storage LUNs that are provided by the storage array. Thus the data flow for a simple write which the RE just needs to store one copy of in its repository is: Host→storage controller→Replication Engine→storage controller→disks (repository storage). Of course in reality, the RE will probably need to associate some metadata with the data and may also need to copy data from one place in its repository to another place in the repository. It may also need to copy data between the primary disks and the repository.
Such an arrangement is illustrated in FIG. 2, in which are additionally illustrated a storage appliance 200 having a splitter 202 and a storage virtualization controller 204 having a splitter 206.
The data flow for a split write according to all of these implementations of the prior art may be shown in simplified form as illustrated in FIG. 3, in a which a host 300 writes data at flow 1 to storage array 302. Storage array 302 flows the data to the primary physical storage 306 at flow 2 and to replication engine 304 at flow 3. Replication engine 304 adds metadata and flows the data and metadata to the storage array 302 at flow 4, and storage array 302 flows the data to the secondary physical storage 308 at flow 5.
Flowing the data through the RE has the following disadvantages:                The data has to make at least an extra two passes across the network and across the busses that connect the Storage array memory to the network. This limits the bandwidth that can be achieved by the solution for any given hardware platform.        If the storage controller implements a data format including check-bytes for data integrity checking then either the RE has to participate in the scheme or the data is unprotected in this part of the data flow.        
It would thus be desirable to have an improved technology for managing storage systems having storage copy services.